Many host applications (e.g., file systems, media players, photo albums, email editors, etc.) that make use of a local storage device usually comprise a “core application” that uses a legacy mass storage path to access content stored on the local storage device (e.g., to play music, view photos, edit email, etc.). In operation, a host application would access the mass storage device via a host file system, which would then manage the mass storage device via a block device driver as logical blocks through a logical block addressing (LBA) scheme (i.e., by conveying block commands (typically standardized commands such as SD or MMC commands) over a physical interface). Host applications also can use a number of “ancillary” storage services designed to ease the management of the stored content by the host application (e.g., searching, indexing, background content preparation, etc.). One such ancillary storage service that is desirable for music content consumption is play list management. In a typical experience, in response to a user request, the music player application automatically proposes one or more songs related to the song just played (e.g., same artist, same genre, same period, etc.) and/or based on knowledge of user preferences (e.g., via usage monitoring). Instead of proposing a song related to a song just played, the music player application can automatically create a play list for the user.
There are several disadvantages associated with this approach. First, this approach provides sub-optimal usage of host resources (e.g., CPU consumption and usage of the storage bus) because it requires that the host device read, interpret, and compare song properties to a set of search criteria (e.g., given artist, given genre) for the whole file library. In the case of a high-capacity storage local storage device (e.g., 8 GB and up), this process can consume significant host CPU resources. Second, this approach provides a sub-optimal processing time-impact on the user experience, as a large amount of data would be read from the local storage device and processed in the host. Also, in the case of a removable storage device that is moved from a source host to a destination host, the content stored on a removable device is typically reprocessed by the play list manager of the destination host, and the processing done on the source host (e.g., searching according to mostly-used criteria) cannot be re-used on the destination host. Similarly, the play list manager on the destination host does not have knowledge of the user preference history from the source host. Another problem for mobile host devices lies in the heterogeneity of the operating systems and platforms (e.g. Symbian, Windows Mobile, Google Android, in addition to a variety of closed, proprietary OSs etc.). Unlike the PC environment where there is only one OS (Windows), a given player including the play list management feature needs to be ported/integrated on a variety of platforms, which poses a problem of scalability.